1. Field of the Invention
The present invention relates to migrating client protocols for access to a wide area network to an arbitrary protocol, and, in particular, migrating point to point protocol PPP, such as PPP over Ethernet (PPPoE) or PPP over Asynchronous Transfer Mode (PPPoA) to the Internet Protocol (IP) over Ethernet.
2. Description of the Related Art
Networks of general purpose computer systems connected by external communication links are well known. The networks often include one or more network devices that facilitate the passage of information between the computer systems. A network node is a network device or computer system connected by the communication links.
Information is exchanged between network nodes according to one or more of many well known, new or still developing protocols. In this context, a protocol consists of a set of rules defining how the nodes interact with each other based on information sent over the communication links. The protocols are effective at different layers of operation within each node, from generating and receiving physical signals of various types, to selecting a link for transferring those signals, to the format of information indicated by those signals, to identifying which software application executing on a computer system sends or receives the information. The conceptually different layers of protocols for exchanging information over a network are described in the Open Systems Interconnection (OSI) Reference Model. The OSI Reference Model is generally described in more detail in Section 1.1 of the reference book entitled Interconnections Second Edition, by Radia Perlman, published September 1999, which is hereby incorporated by reference as though fully set forth herein.
Communications between nodes are typically effected by exchanging discrete packets of data. Each packet typically comprises 1] header information associated with a particular protocol, and 2] payload information that follows the header information and contains information that may be processed independently of that particular protocol. In some protocols, the packet includes 3] trailer information following the payload and indicating the end of the payload information. The header includes information such as the source of the packet, its destination, the length of the payload, and other properties used by the protocol. Often, the data in the payload for the particular protocol includes a header and payload for a different protocol associated with a different, higher layer of the OSI Reference Model. The header for a particular protocol typically indicates a type for the next protocol contained in its payload. The higher layer protocol is said to be encapsulated in the lower layer protocol. The headers included in a packet traversing multiple heterogeneous networks, such as the Internet, typically include a physical (layer 1) header, a data-link (layer 2) header, an internetwork (layer 3) header and a transport (layer 4) header, as defined by the Open Systems Interconnection (OSI) Reference Model.
Some protocols span the layers of the OSI Reference Model. For example, the Ethernet local area network (LAN) protocol includes both layer 1 and layer 2 information. The International Electrical and Electronics Engineers (IEEE) 802.3 protocol, an implementation of the Ethernet protocol, includes layer 1 information and some layer 2 information.
One such layer 2 protocol is the Point to Point Protocol (PPP) between a host computer on a local area network and a network node that provides access to a wide area network, such as the Internet. Some protocols, including PPP, pass protocol-related information among two or more network nodes in special control packets that are communicated separately and which include a payload of information used by the protocol itself rather than a payload of data to be communicated for another application. These control packets and the processes at network nodes that utilize the control packets are said to be in another dimension, a “control plane,” distinct from the “data plane” dimension that includes the data packets with payloads for other applications. For example, authentication information used to authenticate users and layer 3 address assignment information used by routers to direct data packets according to their layer 3 addresses are passed between nodes in PPP control messages in the PPP control plane.
PPP provides a standard method for transporting any of multiple protocol data packets (also called frames, datagrams and cells, and used interchangeably herein) over point-to-point links. PPP is defined in an Internet Engineering Task Force (IETF) request for comments document (RFC) numbered 1661, dated July 1994, the entire contents of which are hereby incorporated by reference as if fully set forth herein. Copies of RFC 1661 and other RFCs cited below are available at the World Wide Web domain ief.org. PPP has been used extensively to connect users at a home site to a remote network using modems and telephone copper loop infrastructure. PPP provides a robust control plane for signaling line characteristics, network protocol parameters, and user-level authentication. In large service provider networks, the user authentication models are generally well entrenched, including, but not limited to, custom-built applications for communicating policy to network equipment and to track billing information.
For applications in which multiple hosts on a shared Ethernet establish PPP sessions to multiple destinations via one or more bridging modems, a PPP over Ethernet (PPPoE) specification has been developed. PPPoE is intended to be used with broadband remote access technologies that provide a bridged Ethernet topology, when access providers wish to distinguish different users connected via the same modem to the remote network. PPP provides this distinction by opening different sessions with different users. PPPoE is described in IETF RFC 2516, the entire contents of which are hereby incorporated by reference as if fully set forth herein.
For some applications, a digital subscription line (DSL) protocol used by bridging modems is combined with an Asynchronous Transfer Mode (ATM) data link layer protocol. A specification for PPP over ATM (PPPoA) has been developed and used extensively in this context. PPPoA for IP data packets in a PPP payload is described in IETF RFC 2364, the entire contents of which are hereby incorporated by reference as if fully set forth herein.
There is a trend among network service providers to move to Ethernet and IP as the only layer two and layer three protocols between end nodes at a user site and end nodes on the remote network to which access is sought. One reason given for this trend is a desire to make use of IP-based quality of service (QoS) capabilities available in access network equipment. Another reason given is to reduce complexity because data packets can be transmitted from one portion of the network infrastructure to another without translating between layer two protocols. Another reason given is that using IP over Ethernet will improve efficiency of bandwidth utilization compared to a mixture of many protocols.
One approach is to eliminate PPP, PPPoE and PPPoA, and provide the PPP functions using IP-based functions. For example, it has been proposed to use International Electrical and Electronics Engineers standard 802.1x or web portal methods for authentication, and to use the Dynamic Host Configuration Protocol (DHCP) for assigning IP addresses. A justification offered for this approach is that, when all encapsulated data packets are IP, the multi-protocol encapsulation capability of PPP is not valuable.
There are some disadvantages to eliminating PPP. The existing IP-based functions do not perform all the functions performed by PPP. Some of these protocols would have to be extended to perform the missing functions. For example, DHCP would have to extended to perform user authentication and integration, configure link-level parameters such as maximum reception unit (MRU), included a connection “keep-alive” mechanism, among other tasks, in order to encompass all of the functionality that PPP offers today. An extant RFC on DHCP authentication is directed to authenticating the DHCP messages themselves to ensure that they did not get altered in transit, rather than authenticating the user and hooking into an Authentication, Authorization, Accounting (AAA) server like RADIUS at the BRAS to make this happen. Furthermore, DHCP authentication as described in the RFC is not available in most implementations today. Furthermore, PPP provides a mechanism for detecting when a session is active and available so that reallocation of an IP address or billing can take place on session termination. DHCP does not have any mechanism today apart from a lease timeout. As stated above, in large service provider networks, PPP-based user authentication, billing mechanisms, policy dissemination, and some other functions are generally well entrenched and costly to replace with IP-based functions.
A specific example of problems that arise in migrating remote access to IP over Ethernet infrastructure occurs with DSL/ATM data packets. For many internet service providers (ISPs) an access network lies between a DSL modem bank controlled by a DSL Access Module (DSLAM) and a Broadband Remote Access Server (BRAS) host. This access network is often based on an ATM infrastructure and uses PPPoA to connect remote users to the BRAS. If this access network is converted to a Gigabyte Ethernet infrastructure, PPPoA will fail because Gigabyte Ethernet does not support ATM protocol data packets (called ATM cells).
In one approach to resolving this problem, PPPoA data packets are translated to PPPoE data packets and then the PPPoE data packets are sent over the Gigabyte Ethernet access network. While suitable in some circumstances, there are several disadvantages to this approach. The “translated” PPPoE session does not look exactly like other PPPoE sessions at the BRAS. For example, a proposal brought to the DSL Forum (DSLForum2004.343) requires additional constraints beyond RFC 2516 on PPPoE signaling at the BRAS. Specifically, this proposal mandates sending a PPP Active Discovery Termination (PADT) message at the close of a PPPoE session, and mandates responding to unknown PPPoE source traffic with PADTs; among other changes.
Another disadvantage is that PPPoE as defined in RFC 2516 imposes a maximum transmission unit (MTU) of 1492 bytes for PPP frames carried over Ethernet. This limitation stems from the standard Ethernet maximum MTU of 1500, and the fact that the PPP and PPPoE header is 8 bytes. PPPoA typically allows a full 1500 bytes, and PPPoA equipment at customer premises may not be compliant in allowing the MTU to be reduced. Some customers stay with PPPoA primarily because of the increased MTU size. Thus even if it is possible to negotiate an MTU of 1492 with PPPoA, it is not adequate for some customers.
Consequently, PPPoA to PPPoE translation in the form being circulated at the time of this writing is not transparent to either the BRAS or the customer premises equipment (CPE).
Even if PPPoA is successfully translated to PPPoE, there are disadvantages to using PPPoE on an Ethernet access network. Many network devices on an Ethernet access network are intelligent nodes that can filter and optimize the switching of data packets based on an IP datagram in the Ethernet payload of an Ethernet data packet. These devices are stymied if the first protocol in the Ethernet payload is not IP but something else, such as PPPoE.
Based on the foregoing, there is a clear need for techniques that migrate PPP, PPPoE and PPPoA functionality to IP over Ethernet infrastructure but that do not suffer the disadvantages of the prior art approaches. In particular, there is a need for techniques that allow Ethernet data packets (also called herein Ethernet frames) to transport IP data without intervening PPP headers.
The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not to be considered prior art to the claims in this application merely due to the presence of these approaches in this background section.